This document describes the ISDNSerial driver which simulates a serial driver and modem using an ISDN Nubus card. This allows one to use the ISDN card with Apple Remote Access and other programs that normally only work with modems.
･ What is it?
The ISDN Serial Driver is makes it possible to access an Apple or SAT/SAGEM Planet or Meet-Me ISDN Nubus card via the serial driver interface as well as via the interface provided with the card. This is a standard driver which accepts most of the Control commands accepted by the normal serial drivers (although some of them do nothing). It registers itself with the Communications Resource Manager (CRM) so that any program which uses the CRM to find serial drivers will be able to use this driver. This includes Apple Remote Access, which is the main use for ISDNSerial.
In order to make programs that expect to use a modem able to use the ISDN card instead, this driver also simulates a simple modem. It accepts many of the basic Hayes compatible commands, as well as a few of its own intended to give one more control over the ISDN line.
Also included with this package is a script that allows this driver to be used with Apple Remote Access. Once the driver and script are installed, one can create an ARA connection document which uses the driver and script to place or accept calls via the ISDN line.
･ Installation
To install the driver and ARA script, simply drag them to the closed System Folder in the Finder. It will place them both in your Extensions folder, where they belong. You must have System 7.0 and any one of an Apple or SAT/SAGEM Planet or Meet-Me ISDN card (and associated software) to use this driver. Future plans call for support of other ISDN cards, but those three are the only ones supported at this time. After installing these files you must reboot your machine to have them take effect. ISDNSerial will display its icon as you boot if it successfully finds an ISDN card it supports.
This is all you need to know to use the driver with Apple Remote Access. If you want to know more of the technical details about how it works, they are described below. Otherwise, install the two files and reboot, configure the Remote Access Setup control panel to use them, and create a connection document to place a call. You of course must do this on two machines if one is answering a call placed by the other. The connection document is only required on the calling machine.
･ Copyright and other legalese
Copyright ｩ 1994-1996
The Regents of The University of Michigan
All rights reserved
Permission is granted to use this software for noncommercial education and research purposes. Permission to copy, distribute, modify or otherwise create derivative works of this software is not granted.
This software is provided as is, without representation as to its fitness for any purpose, and without warranty of any kind, either express or implied, including without limitation the implied warranties of merchantability and fitness for a particular purpose. The Regents of the University of Michigan shall not be liable for any damages, including special, indirect, incidental, or consequential damages, with respect to any claim arising out of or in connection with the use of the software, even if it has been or is hereafter advised of the possibility of such damages.
･ How it works
In order to make it possible to use both B channels on each ISDN line simultaneously for separate calls, the driver is registered twice for each ISDN card installed. Each time it actually registers two drivers, one for input and one for output. This means there are a total of four drivers registered per ISDN card when this program is installed. For a card in slot "C" (for example) they are called ISDNSerC0In, ISDNSerC0Out, ISDNSerC1In, and ISDNSerC1Out. The two pairs (distinguished by the 0 or 1 in the name) are identical, a program can use either of them, so long as no other program is using it. This version of the driver does not support any form of bonding between B channels. Each call uses a single B channel.
Within each pair, it is not necessary to use both drivers. If a program opens only one of them, then that one can be used for both input and output. If both are opened, then .ISDNSerxnIn must be used for input and .ISDNSerxnOut for output. In this case it is possible to do both input and output simultaneously, while if only one is opened, no operation will begin until all previous ones have completed. All this may sound complex, but it is the way most serial drivers work on the Macintosh.
In addition to implementing the serial driver interface, this program also simulates a subset of the Hayes modem command set. This allows you to configure the ISDN connection, make calls, answer calls, etc. These commands are recognized only when the driver is in command mode. One can enter command mode from online mode in one of two ways. If a write operation consists of exactly the three characters "+++" then the driver will enter command mode but not close the connection. This is generally impossible to do from a terminal emulator since each of the pluses will be passed to the tool as a separate write operation. The other way to enter command mode is to ask the driver to drop DTR. This also closes any active connection. You must raise DTR again before the driver will recognize any output.
If the connection closes spontaneously, the driver will return the message "cr/lf/NO CARRIER/cr/lf" the next time the program reads from the driver. For this to work correctly, the currently active program must call SystemTask (or the equivalent) periodically. In general this is a requirement for commands to work correctly. Since the driver can be called from interrupt routines and some commands can't be executed at that time, commands are deferred to SystemTask time if necessary.
The code used to install the driver is an adaptation of driver.c version 2.1.8 by Pete Resnick (resnick@cogsci.uiuc.edu) and others.
･ Commands recognized
This section describes the commands accepted by the simulated modem that is built into ISDNSerial. If all you want to do is use it with ARA, nothing in this section is necessary. It is intended only for those who want to use ISDNSerial for other purposes and hence need to know how it really works.
The commands recognized are as follows:
ATZ
AT&F
Both of these disconnect any existing call and reset the ISDN configuration to the default state. There is no way to specify a "stored configuration" for use by ATZ, so it is currently a synonym for AT&F, which loads the "factory default configuration."
ATE[0|1]
This commands turns on or off (for 1 or 0 respectively) echoing of commands.
ATQ[0|1]
This turns on or of (for 0 or 1 respectively) command responses such as "OK", "ERROR", etc.
ATM[0-9]
ATL[0-9]
These commands, which control the modem speaker, are ignored.
AT*TTool name
Both of the ISDN cards currently supported by ISDNSerial use the Communications ToolBox as their primary programming interface. This command allows you to specify the name of the tool to be used if necessary (which it rarely will be). Other cards that might be supported in the future will not necessarily use the Communications ToolBox, and this command will not be legal for them. In fact it may be removed entirely in the version that supports those cards, so it should not be used unless absolutely necessary.
Anything after the *T on the same input line is taken to be the name of a CTB tool that is to be used instead of the default for the card. If used, this command must be the first command issued since most other commands cause the CTB tool to be opened after which it can't be changed. Leading and trailing blanks become part of the name. This driver is meant to work with the CTB tools for the Apple or one of the SAT/SAGEM ISDN cards, but it may also work with other CTB tools.
AT*CConfig data
Anything after the *C is passed to the CMConfig entry of the CTB tool. It will normally be one or more keyword/value pairs which set configuration options for the tool. For example "AT*C RateAdaption NoBRA" to set the rate adaption for the Apple card. See the documentation for your ISDN card to determine what is legal in this command.
AT*O
This prints out the current configuration of the tool (assuming that ATQ1 has not been given eariler).
ATA
This command waits for an incoming call. When one is received, the message "CONNECT" is returned, assuming the driver is not in quiet mode (ATQ1).
ATDTxxxxx
This is the command used to place a call. Everything after the DT is taken to be the phone number to be called. When the call is placed, the driver returns the message "CONNECT". If it fails it returns "NO CARRIER". The cause of failure is not returned in this version. Synonyms for this command are ATTD, ATDP, and ATPD.
ATH[0]
This command causes the current connection (if any) to be closed. It is only relevant if you got into command mode using the "+++" trick described above.
ATO[0]
This will get you back online if you entered command mode using the "+++" trick. Otherwise it is an error.
AT*D 'Tool name' 'Config string' 'Phone number'
The three parameters can be enclosed in either single quotes or double quotes. If they contain no internal blanks, the quotes are not necessary. This command is a way to specify all the information necessary to make a connection on one command. It is essentially a combination of the following commands in this order:
AT*TTool name (if the tool name is not a null string)
ATZ
AT*CConfig string
ATDTPhone number or ATA (if the phone number is null or missing)
The reason for having this command is to make it possible for the AppleTalk Remote Access script to issue one command and then wait essentially forever for it to complete. Since these scripts are executed during boot when no one is calling SystemTask, commands may take a very long time to complete and executing a series of them is difficult to do reliably. It also has the advantage of being considerably faster than executing the commands separately.
AT*R[0|1]
This command controls whether the driver and simulated modem state is reset when the driver is closed. Normally it is, but if you give the command "AT*R1" the driver will save its state when it is closed so that it will be in the same state when it is opened again. This allows you to configure things using one program (perhaps a terminal emulator) and then use the configuration in another program (perhaps a network connectivity program that allows less configuration control). The disadvantage of this is that quite a lot of memory will remain allocated in the System Heap even when the driver is closed.
